Systems and methods for providing local hardware limit management and enforcement

ABSTRACT

Systems and methods for providing local hardware limit management and enforcement are described. One embodiment includes a system for managing and enforcing hardware limits on a system on chip (SoC). The system includes a plurality of chip components provided on a system on chip (SoC). A network of local limit manager (LLM) components is distributed on the SoC. Each LLM component is in communication with a corresponding sensor module that monitors one or more of the chip components. Each LLM component comprises a generic hardware structure for enforcing one or more hardware limits associated with the corresponding sensor module.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of the priority of U.S. ProvisionalPatent Application No. 61/985,938, entitled “Systems and Methods forProviding Local Hardware Limit Management and Enforcement” and filed onApr. 29, 2014 (Attorney Docket No. 17006.03336U1), which is herebyincorporated by reference in its entirety.

DESCRIPTION OF THE RELATED ART

Portable computing devices (e.g., cellular telephones, smart phones,tablet computers, portable digital assistants (PDAs), and portable gameconsoles) continue to offer an ever-expanding array of features andservices, and provide users with unprecedented levels of access toinformation, resources, and communications. To keep pace with theseservice enhancements, such devices have become more powerful and morecomplex. Portable computing devices now commonly include a system onchip (SoC) comprising one or more chip components embedded on a singlesubstrate (e.g., one or more central processing units (CPUs), a graphicsprocessing unit (GPU), digital signal processors, etc.).

During operation of such devices, it is desirable to prevent the chipcomponents from exceeding certain physical limits (e.g., temperature,current or transient (di/dt) limits), which can lead to device failure.Device and component manufacturers may also desire to reduce the designmargin between the physical limits and the operating conditions of thedevice. The time constants for these limits can vary greatly. Forexample, transient events in the range of 1-2 nanoseconds may lead tovoltage droop and brown-out failure. Transient events are dependent onthe power density and idle-to-on, on-to-idle transition times of certaincomponents (e.g., CPU, GPU, DSP), on-die capacitance, and packageinductance. Cost and form-factor requirements drive package inductanceup and on-die capacitance down, making the transient current problemworse.

Present consumption limits of a switch mode power supply (SMPS) and thebattery in the power delivery network (PDN) may involve time constantsin the range of 100 nanoseconds to 1 microsecond. In such cases, currentlimits must be enforced for each SMPS and for the battery. It ispossible to exceed the battery limit but not any SMPS limit. It is alsopossible to exceed a single SMPS limit without exceeding the battery orany other SMPS limit. This is further complicated by the efficiencylosses of the SMPS, which varies with load current, voltages, and SMPSmode. Thermal limits may involve time constants in the range of 1millisecond to 50 milliseconds. If a thermal limit is exceed, chipcomponents may be damaged. However, leakage current has a strongtemperature dependency and can be a significant portion of total powerfor some die material and workloads.

Current solutions for managing and enforcing hardware limits managementsense an undesirable event and then initiate a mitigation action toprevent the condition from getting worse. Typically, hardware isresponsible for ensuring the limit is enforced within some bounds.Software solutions are generally ineffective for sensing and managinglimits for events below approximately 100 microseconds. Furthermore,non-real-time software solutions, such as employed in many operatingsystems, are subject to indeterminism and cannot be relied on to handleevents even occurring in 100 microsecond range.

A common solution for hardware limit management and enforcement is touse a centralized microcontroller with real-time firmware running on thedie or a pure hardware solution, each of which have limitations anddisadvantages. While dedicated on-die microcontrollers are flexible andmuch easier to design because the firmware running on themicrocontroller can be changed post-silicon, they consume more area andare generally not as efficient as a pure hardware solution. They alsorequire all of the sensor data to be routed to the centralizedmicrocontroller for processing and then mitigation routed back out tothe areas that need mitigation. All of this data movement requires timeand makes it more challenging to get all the sensors read and decisionsmade within real-time constraints. Pure hardware implementations tend tobe limited and customized to work with a particular hardware component.Therefore, they require significant design effort from each componentteam and are often not portable across projects or process technologies.While such implementations are capable of achieving faster responsetimes, they struggle to handle transient events in the range of 1-2nanoseconds or below.

Accordingly, there is a need for improved systems and methods formanaging and enforcing hardware limits in a SoC.

SUMMARY OF THE DISCLOSURE

Systems and methods are disclosed for providing local hardware limitmanagement and enforcement. One embodiment is a system for managing andenforcing hardware limits on a system on chip (SoC). The systemcomprises a SoC having a plurality of chip components and aninterconnected network of local limit manager (LLM) components. The LLMcomponents are dispersed over an area of the SoC. Each LLM component isin communication with a corresponding sensor module that monitors one ormore of the chip components. Each LLM component comprises a generichardware structure for enforcing one or more hardware limits associatedwith the corresponding sensor module.

Another embodiment is a method for providing hardware limit managementand enforcement. One such method comprises: a sensor module monitoring achip component on a system on chip (SoC); storing sensor data from thesensor module in a local limit management (LLM) hardware component;storing a hardware limit associated with the sensor module in the LLMhardware component; comparing the sensor data to the hardware limit; andif the sensor data exceeds the hardware limit, initiating a predefinedthrottling action for enforcing the hardware limit.

BRIEF DESCRIPTION OF THE DRAWINGS

In the Figures, like reference numerals refer to like parts throughoutthe various views unless otherwise indicated. For reference numeralswith letter character designations such as “102A” or “102B”, the lettercharacter designations may differentiate two like parts or elementspresent in the same Figure. Letter character designations for referencenumerals may be omitted when it is intended that a reference numeral toencompass all parts having the same reference numeral in all Figures.

FIG. 1 is a block diagram of an embodiment of a system for providinghardware limit management and enforcement in a system on chip (SoC).

FIG. 2 is a block diagram illustrating an embodiment of a local limitmanager (LLM) component.

FIG. 3 is a flowchart illustrating an embodiment of a method forproviding local hardware limit management and enforcement in the systemof FIG. 1.

FIG. 4 is a combined block/flow diagram illustrating an embodiment of amethod for providing dynamic current budget allocation in the system ofFIG. 1.

FIG. 5 is a flowchart illustrating another embodiment of a method forproviding dynamic current budget allocation.

FIG. 6 is a combined block/flow diagram illustrating an embodiment of ageneric hardware structure for implementing the local limit manager(LLM) components in the system of FIG. 1.

FIG. 7 is a block diagram of an embodiment of a portable computer devicefor incorporating the system of FIG. 1.

DETAILED DESCRIPTION

The word “exemplary” is used herein to mean “serving as an example,instance, or illustration.” Any aspect described herein as “exemplary”is not necessarily to be construed as preferred or advantageous overother aspects.

In this description, the term “application” may also include fileshaving executable content, such as: object code, scripts, byte code,markup language files, and patches. In addition, an “application”referred to herein, may also include files that are not executable innature, such as documents that may need to be opened or other data filesthat need to be accessed.

The term “content” may also include files having executable content,such as: object code, scripts, byte code, markup language files, andpatches. In addition, “content” referred to herein, may also includefiles that are not executable in nature, such as documents that may needto be opened or other data files that need to be accessed.

As used in this description, the terms “component,” “database,”“module,” “system,” and the like are intended to refer to acomputer-related entity, either hardware, firmware, a combination ofhardware and software, software, or software in execution. For example,a component may be, but is not limited to being, a process running on aprocessor, a processor, an object, an executable, a thread of execution,a program, and/or a computer. By way of illustration, both anapplication running on a computing device and the computing device maybe a component. One or more components may reside within a processand/or thread of execution, and a component may be localized on onecomputer and/or distributed between two or more computers. In addition,these components may execute from various computer readable media havingvarious data structures stored thereon. The components may communicateby way of local and/or remote processes such as in accordance with asignal having one or more data packets (e.g., data from one componentinteracting with another component in a local system, distributedsystem, and/or across a network such as the Internet with other systemsby way of the signal).

In this description, the terms “communication device,” “wirelessdevice,” “wireless telephone”, “wireless communication device,” and“wireless handset” are used interchangeably. With the advent of thirdgeneration (“3G”) wireless technology and four generation (“4G”),greater bandwidth availability has enabled more portable computingdevices with a greater variety of wireless capabilities. Therefore, aportable computing device may include a cellular telephone, a pager, aPDA, a smartphone, a navigation device, or a hand-held computer with awireless connection or link.

FIG. 1 illustrates an embodiment of a system on chip (SoC) 102incorporating a hardware limits management system 100. The SoC 102embodying the 100 hardware limits management system 100 may beimplemented in any computing device, including a personal computer, aworkstation, a server, a portable computing device (PCD), such as acellular telephone, a portable digital assistant (PDA), a portable gameconsole, a palmtop computer, or a tablet computer. As illustrated in theembodiment of FIG. 1, the SoC 102 comprises various components,including sensor modules 106 and chip components 104 to be monitored bythe sensor modules 106 and for which the hardware limits managementsystem 100 enforces one or more hardware limits. Chip components 104 maycomprise central processing units (CPUs), graphics processing units(GPUs), digital signal processors (DSPs), video codecs, or any otheron-die component having hardware limits to be monitored and enforced viathe hardware limits management system 100. A power management integratedcircuit (PMIC) 108 may be incorporated either on the SoC 102 or as aseparate chip. It should be appreciated that the hardware limitsmanagement system 100 may be implemented using any desirable types,quantities, and configurations of sensor modules 106.

As illustrated in FIG. 1, the hardware limits management system 100generally comprises a hierarchical limits management/enforcementframework comprising a global limits manager (GLM) component 110, aplurality of domain limits management (DLM) components 112, and adistributed hardware network 120 of local limits management (LLM)components 114. The SoC 102 may include a single GLM component 110 forbudgeting allocation of resources to a plurality of DLM components. Itshould be appreciated that individual instances of a DLM component areidentified with reference numbers 112 a, 112 b, and 112 c andcollectively identified with reference number 112). In an embodiment,the GLM component 110 budgets allocation of power supply current via,for example, battery current budget allocation module(s) 116.

Each DLM component 112 a, 112 b, and 112 c may control budget allocationfor one or more associated LLM components 114 in a parent/childrelationship. As illustrated in FIG. 1, a parent DLM component 112 a maycomprise a DLM budget allocation module 118 a for controlling budgetallocation to LLM components 114 a 1, 114 a 2, and 114 a 3. A parent DLMcomponent 112 b may comprise a DLM budget allocation module 118 b forcontrolling budget allocation to LLM components 114 b 1, 114 b 2, and114 b 3. A parent DLM component 112 c may comprise a DLM budgetallocation module 118 c for controlling budget allocation to LLMcomponents 114 c 1, 114 c 2, and 114 c 3. As described below in moredetail, each DLM component 112 on the SoC 102 may correspond to aseparate voltage domain having a dedicated switched mode power supply(SMPS). It should be appreciated that any number of GLM, DLM, and LLMcomponents may be incorporated on SoC 102.

The distributed network 120 of LLM components 120 may be dispersed overan arca of the SoC 102 in any desirable configuration and/or quantity asneeded to accommodate design considerations. It should be appreciatedthat the distributed network 120 may be designed to reduce the margin(e.g., voltage, current, thermal & power margins) that may otherwise beleft on the table to ensure the limit management/enforcement platform isstable. The margin reductions provided by the distributed network 120may offset the power cost of the hardware, which can be translated intooverall performance improvement, power reduction or Bill of Materials(BOM) cost reduction.

One of ordinary skill in the art will appreciate that the distributednetwork 120 may provide a relatively small footprint, yet highlyconfigurable and reusable, set of limit management blocks (e.g., LLMcomponents 114) that various chip component teams (e.g., CPU, GPU, DSP,modem, etc.) may use to enforce local limits. The LLM components 114 maybe interconnected to form the distributed network 120. In this manner,the LLM components 114 provide a hardware infrastructure, which issimultaneously capable of fast, local, hardware-based limits enforcementand capable of global optimizations across multiple units. The LLMcomponents 114 may provide a generic set of mechanisms to map eachcomponent team's unique sensors to their unique mitigation mechanisms,which may obviate the need for customization. Each software driver maybe exposed to the same generic register structures within the LLMcomponent 114 for each unique component. Software (e.g., limitsmanagement module(s) 109) may configure the hardware behavior by settingcertain control register bits inside the LLM component 114. Furthermore,each LLM component 114 may be timing converged to work with the chipcomponent(s) 104 it is management.

In an embodiment, the generic hardware structure of the LLM components114 may be configured with various unique capabilities for managing andenforcing hardware limits. Each LLM component 114 may map sensor inputfrom any sensor module 106 (e.g., current, power, temperature, voltage,SMPS efficiency, etc.) into a generic structure. The structure can beconfigured to aggregate and average samples over a period of time, whichmay enable the structure to operate on sensor data coming in as fast asthe clock component it is managing. For a typical CPU, this could be inthe range of 2-4 GHz or just a few hundred picoseconds. For a slowercomponent (e.g., an audio engine operating at 100 MHz), this may be inthe range of 10 nanoseconds. Furthermore, the aggregation enables anysensor data rate to be extended to any needed time constant, evenextended out to ranges in the milliseconds, seconds, minutes, or hours).The structure may maintain a history of previous samples and a rollingaverage of previous samples. In the embodiment of FIG. 6, afirst-in-first-out (FIFO) register may be used, although other methodsand structures may be employed. A fixed time period clock reference mayalso be used to ensure all aggregated samples are equally spaced intime.

The generic structure may comprise one or more coefficients used tocompute a threshold of the stored sensor data and compare it to a limitfor that particular sensor type. Coefficients can be combined (e.g.,through multiplication, addition, shifting, etc.) with each of the termsin the sensor storage structure. Because the sensor data may be equallyspaced in time, various discrete time math functions may be applied inhardware to the sensor data (e.g., proportional, derivative, integral,etc.) to determine for example: (1) when any mitigation should takeplace; (2) how long the mitigation should be activated; and (3) whichmitigation signals should be asserted.

The generic structure may also store threshold violations, based on anyof the sensors to be combined and mapped to any number of mitigationcapabilities supported by the particular component 104 being monitored(e.g., CPU, GPU, DSP, modem, etc.) For example, a first sensor module106 a running at 1 nanosecond and a second sensor module 106 b runningat 1 millisecond may be configured to simultaneously (yet independently)assert a single mitigation mechanism. Alternatively, the same two sensormodules 106 a and 106 b may both need to be at a certain level for themitigation activity to be activated. Any number of sensor modules 106and thresholds can be combined using any number of logic configurations(AND, OR, NAND, NOR, XOR, etc.). In this manner, a component team needonly hook-up the sensor module(s) and mitigation capabilities unique totheir implementation, and then the corresponding LLM component 114 maybe configured to optimally link those capabilities together along withthe appropriate limits.

Because the sensor modules 106 can run at high clock speeds, the onsetof initial conditions that come before limit violations can be detectedand preemptive mitigation asserted. One example of this is transient(di/dt) limits. Most hardware di/dt schemes rely on a voltage droopdetector to detect that the di/dt event is occurring and then try toinitiate mitigation before it is too late. One embodiment of thissolution identifies the low current consumption condition has beenreached such that a burst of current consumption could cause a voltagedroop. In this case, the mitigation can be initiated at the onset of theinitial condition instead of after it has already started, therebypreventing an excessive di/dt from being possible.

The LLM components 114 may be configured during initialization of theSoC 102 (at boot time), although the configuration may be changed duringrun time without any gaps in limits enforcement. The LLM components 114may be programmed or controlled to enforce limits without sending aninterrupt to software when throttling occurs. Short duration limitviolations can cause problems to conventional mitigation systems becauseit can take more energy to make a change than was saved by making thetransition. The distributed network 120 enables software (e.g., limitsmanagement module 109) to provide guidance to the LLM components 114indicating how long it should enforce the limit through mitigationbefore asserting an interrupt to software. Furthermore, while manyconventional hardware mitigation mechanisms are fast, they are not veryenergy efficient. The LLM components 114 may use a less efficientmitigation mechanism to achieve the needed response time and then, ifmitigation lasts too long, may initiate a more efficient mitigationmechanism that will take more time. These other mechanisms may behardware or software initiated, enabling short duration limits to beeffectively filtered by the LLM components 114.

As mentioned above, the LLM components 114 may be connected together ina hierarchy. Each LLM component 114 in the hierarchy has all of theinformation needed to enforce local limits. For example, each LLMcomponent 114 may know the associated limit(s), the values from theassociated sensor module 106, the thresholds for the limit(s), and themitigation mechanisms available for that particular component. Thesensors may also be extremely fast, and thus the mitigation may also bevery fast, covering a range of time constants with a single generichardware structure. The hierarchy enables the LLM components 114 toshare information about present sensor data and, therefore, allow limitsfor each LLM component 114 to dynamically change. For example, ifseveral components 104 arc sharing a single SMPS, the current limit maybe dynamically divided among those components. Low-level guarantees toeach active component may be enforced, but if several components are notusing much, the other components can access the remaining allowed forits limit. In this regard, budgeting schemes may be employed to ensurethe limits are not violated but also to enable maximum performance ofone or two components when needed. Counters and other mechanisms can beused to ensure transitions to/from mitigation are smooth and have stableresponses. The budgeting may also leverage hardware signaling fromcomponents that have scheduled wakeup/active events.

The GLM/DLM/LLM hierarchy also enables all the current consumption oneach SMPS to be aggregated together and, therefore, SMPS current limitsto be enforced. If this is not the lowest level of the hierarchy (i.e.,LLM), then the DLM component 112 may periodically update the sensorbudgets/limits to each of the child LLM components 114. The same blockcan compute the SMPS efficiency loss and then provide the adjusted(including loss) current back to its parent. In this regard, the generichardware blocks may be placed appropriate to any chip or product powerdevelopment network (PDN) and properly manage current limits at eachSMPS and the battery in the PDN. The GLM/DLM/LLM hierarchy can even beextended to multi-chip implementations using the same components. Itshould be appreciated that the LLM components 114 represent reusablehardware components that can provide limits management for both veryfast and very slow sensors, while also providing a generic map of thosesensors to a component-specific mitigation mechanisms. Software sees thesame generic structure and behavior for each LLM instance, makingsoftware easily portable across multiple chips and platforms.

The hardware limits management system 100 allows performance to bepushed as high as possible in the hierarchy, with the lowest possibledesign margins, yet without exceeding physical limits that would have asignificant impact on the device. One of ordinary skill in the art willappreciate that the hardware limits management system 100 and the sensormodule(s) 106 may enforce any desirable hardware limits, including, forexample, PDN transient current and voltage droop, voltage rail currentlimits, battery current limits (BCL), or temperature limits, as well asany range of sample times and response times.

FIG. 2 illustrates an embodiment of a generic hardware structure forimplementing a LLM component 114. Each instance of the generic hardwarestructure has a corresponding sensor module 208 that monitors one ormore chip components 104 on the SoC 102. Each instance of a sensor/LLMpairing is located in a different area 200 of the SoC 102 to provide thedistributed network 120. In the embodiment illustrated in FIG. 2, thegeneric hardware structure comprises a sensor data register 202, a limitthreshold register 204, and a throttling action register 206. The sensordata register 202 stores the sensor data generated by the sensor(s) 210and controlled via a controller 212. The limit threshold register 204stores one or more limit thresholds for the sensor data. The limitthresholds may be predefined or determined according to one or morestored coefficients, as mentioned above. The throttling action register208 stores data associated with predefined throttling action(s) forinitiating, calculating, and/or controlling corresponding mitigationtechniques. The data stored in the LLM component 114 may be programmedby software (e.g., limits management module(s) 109).

FIG. 6 illustrates another embodiment of a first-in-first-out (FIFO)register 602 for implementing various aspects and functionalityassociated with the LLM component 114. In this embodiment, the sensordata is related to a sensor module 106 comprising a digital power meter(DPM), although it should be appreciated that alternative sensormodules, sensor data, and calculations may be employed. At block 604,the DPM provides a new value to the FIFO register 602. The values arestored in register locations 606, 608, 610, 612, etc. in afirst-in-first-out manner. The values may comprise proportional sensorinput, which may be averages to define a DPM average in a registerlocation 614. The DPM average may be used to calculate integral sensordata, which may be stored in a register location 616. In otherembodiments, the sensor input values may be operated on by other logiccomputations (e.g., subtraction block 618) to calculate derivativesensor data, which may be stored in a register location 620.

One of ordinary skill in the art will appreciate that each instance of asensor/LLM pairing comprises hardware configured to monitor itself(i.e., sensor/LLM hardware). In an embodiment, the sensor module 106comprises a digital power meter (DPM) configured to estimate one or moreof an active current consumption, a leakage current, and a temperature.The sensor/LLM hardware may be configured to compare the sensor valuesagainst known (pre-programmed) limits and take (pre-programmed) actionsto prevent those limits from being exceeded. The sensor/LLM hardware mayprovide short-term limits enforcement for events that are short-livedand self-correcting, as well as events that are long-lived, providingenough time for software to be notified. Software notifications may beused to assist in determining what is happening and to make adjustmentsthat are more globally optimized.

The sensor module 106 and the corresponding LLM component 114 may befunctionally coupled to leverage a computational engine used by bothcomponents. To further illustrate this coupling, an exemplaryimplementation of a digital power meter (DPM) will be described. The DPMprovides an accurate, in-situ, current consumption estimate of one ormore digital design blocks in real time. Both active current and leakagecurrent estimation may be estimated, accommodating changes totemperature, voltage, and frequency at run time. Adjustments for processvariation (per unit) may be made based on calibration duringmanufacturing and testing. Various models may be provided for specificchip components, number of signals being monitored, and operationalfrequency. Analog component current can be modeled based on the signalsused to configure bias current consumption, data rates, and output powerlevels, which may be obtained by the DPM infrastructure.

LLM hardware may be configured to compare the estimated current (fromthe DPM) against limits and/or budgets set by software and initiatepre-defined actions when any of those limits are reached. The limitscomparison may incorporate complex functions and sophisticatedthresholds (e.g., PID=Proportional, Integral, Differential thresholds)may be provided to minimize limit margins. One of ordinary skill in theart will appreciate that various throttling and/or mitigation actionsmay be initiated, including, for example, the assertion of softwareinterrupts, the assertion of local hardware throttling actions, etc.Additional computations using the DPM computation engine may be providedfor LLM hardware functions. Some of these functions may be initiated atperiodic intervals (and triggered automatically with each DPM cycle),while others may only be needed at certain times and be initiated by theLLM hardware. Examples of non-periodic events that initiate computationsinclude frequency or voltage changes, budget allocation changes made bysoftware, etc.

The SoC area 200 and power overhead of the DPM and/or LLM functions maybe minimized. In this regard, DPM and LLM hardware may be tightlydesigned together in order to ensure that the values (e.g., units,binary point locations, scale of time, etc.) produced by the DPM arereadily consumable by the LLM hardware. Furthermore, the DPM/LLMhardware architecture may be highly configurable (e.g., in hardwarethrough, for example, #ifdef statements) so that each instance can bescaled to most closely meet the specific needs of a chip component 104.In this manner, low area and power overhead may be achieved at theexpense of design and non-recurring engineering (NRE) verification NRE.

FIG. 3 illustrates an embodiment of a method 300 implemented by one ormore components in the hardware limits management/enforcement system100. The method 300 is described with reference to a single instance ofthe generic hardware structure for simplicity. At block 302, a sensormodule 106 monitors one or more chip components 104 on the SoC 102. Thesensor module 106 may be configured to generate sensor data formonitoring and enforcing any of the hardware limits described above. Atblock 304, the sensor data from the sensor module 106 is stored in thecorresponding LLM component 114. The sensor data may be stored in afirst register (e.g., sensor data register 202—FIG. 2) or as illustratedin FIG. 6. As mentioned above, the generic hardware structure may storevarious types of data for enforcing the hardware limits. At block 306,the generic hardware structure may store one or more thresholds in athreshold register 204. The threshold register 204 may also storecoefficients used to determine whether the sensor data exceeds thethresholds. At block 308, the generic hardware structure may also storedata for predefined throttling action(s) to be initiated if the sensordata exceeds the thresholds. The throttling action data may be stored ina throttling actions register 206. At block 310, the sensor data may becompared to the thresholds to determine if a hardware limit has beenexceeded or a condition exists that may lead to the hardware limit beingexceeded. If the hardware limit is exceeded (decision block 312), thethrottling actions register may be accessed to initiate an appropriatemitigation action for enforcing the hardware limit. If the hardwarelimit is not exceeded, flow may generally return to block 302.

It should be appreciated that some of the stored data described inconnection with FIG. 3 may be pre-configured via software. The softwaremay change the pre-configured values while the hardware is enforcing thelimits without losing the limits enforcement capability. In anembodiment, this may be implemented with a set of pre-configuredregisters that software can adjust and then allowing software to commandthe hardware to switch between the two groups of pre-configuredregisters. In this manner, the hardware may do the switch at a time whencomputations are not being done and ensure all limits are still enforcedwith a self-consistent set of pre-configured register contents.Furthermore, the software can make a global adjustment to the LM systemto improve performance when, for example, significant, long-termuse-case changes occur in the system.

It should be appreciated that software can make various globaloptimizations to the hardware limits management system 100. In anembodiment, the optimization software may reconfigure pre-programmedvalues in the hardware limits management system 100. In this manner, thehardware limits management system 100 may be changed while runningwithout impacting or corrupting the limits, thresholds, or othercomputations. In other words, the hardware limits management system 100suffers no loss of limit enforcement capability during a configurationchange.

As illustrated in FIG. 4, the GLM/DLM/LLM hierarchical architecture ofthe hardware limits management/enforcement system 100 may providevarious budget allocation features. The battery current capability of adevice incorporating the SoC 102 may be divided up among various powerrails in the system. A DLM component 112 may comprise a budgetingalgorithm for each SMPS in the PDN. FIG. 4 illustrates a DLM component112 a comprising a DLM current budget allocation module 118 a for anassociated SMPS 404 a. The GLM 110 may comprise a battery current budgetallocation module 116 configured to manage and divide the totalavailable current by percentages (e.g., Weighted Binary Budgets) firstfrom the battery to each SMPS 404 directly connected to the battery.This process may be repeated for each SMPS 404 in the PDN. In thismanner, the battery current may be divided into current limits(eventually for each chip component 104). With respect to DLM component112 a, each child LLM component 114 a 1, 114 a 2, and 114 a 3 knows apresent current limit as allocated through the hierarchy from GLM 110 toDLM component 112 a.

It should be appreciated that the GLM component 110 or the DLM component112 may be configured to provide global optimization and allocation ofbudgets to each LLM component 114. Each LLM component 114 can enforcethe allocated budgets using, for example, hardware throttling mechanism,with low enough latency to prevent hard-failures and provide sufficienttime for GLM 110 to be notified and make a global optimizationadjustment. Software management overhead may be reduced because it nolonger needs to monitor the system directly, instead relying on the LLMcomponents 114 to signal if a pre-programmed limit threshold is crossed.One of ordinary skill in the art will appreciate that the GLM component110 or the DLM component 112 may interface with other logic, including,for example, scheduler mechanisms and DCVS algorithms.

Referring to FIGS. 4 & 5, the hardware limits management system 100 mayalso provide dynamic current budget allocation based on requests fromthe LLM components 114. If an LLM component 114 has reached a limit andneeds more current budget, then it makes a request to the DLM component112. LLM component 114 a 1, 114 a 2, and 114 a 3 may provide request406, 408, and 410, respectively, to the DLM component 112 a. The DLMcurrent budget allocation module 118 a may process requests in priorityorder according to a dynamic current allocation priority. Dynamiccurrent allocation priority may comprise an ordered binary value, inwhich lower values have higher priority. An algorithm may iteratethrough the LLM instances according to the dynamic current allocationpriority. For each LLM with a valid current request, the request issubtracted from the dynamic allocation budget. DLM component 112 a mayprovide the updated allocated budgets to the LLM components 114 a 1, 114a 2, and 114 a 3 via response 416, 418, and 420, respectively. It shouldbe further appreciated that the GLM component 110 may dynamicallyallocate budgets to DLM component 112 a via appropriate requests 412 andresponses 414. In other embodiments, requests for more current budgetmay occur if a chip component is consuming more current than budgeted.In this case, it may not have to be initiated because of a scheduledevent.

FIG. 5 illustrates an embodiment of a dynamic budget allocation methodinitiated by an event scheduling function provided by a chip component104. Some chip components 104 may have schedulers and periodically wakeup to transmit or receive information. These events are scheduled andsignaling from these components can be sent to a LLM component 114(block 502) in advance of the event. The new power required (which maybe different for different rails) may be known based on the mode ofoperation & bit error rate, distance from the base station, etc. Thetransmit/receive (Tx/Rx) power may be a significant portion of thebattery limit. Therefore, it may be desirable to link the schedulingfunction to the dynamic allocation algorithm in the LLM component 114.

To facilitate this capability, the scheduler may assert a signal to thecorresponding LLM component indicating that the dynamic power increaserequired for the Tx/Rx event be provided. The LLM component would thensend the corresponding current request(s) to the parent DLM component(block 504) along with the extra current required. The extra currentrequired may be based on some knowledge of the mode and power levels ofthe chip component 104. This may be known to the component schedulermaking the request. The current required may be encoded and provided tothe DPM for modeling the active current consumption anyway. The LLMcomponent can determine the amount of current to request from the parentDLM component. The parent DLM component may send appropriate requests(block 506) and receive response request (block 508) from the GLMcomponent 110, as needed. At block 510, the parent DLM component updatesthe budget allocation to the child LLM components.

As mentioned above, the hardware limits management system 100 may beincorporated into any desirable computing system. FIG. 7 illustrates thehardware limits management system 100 incorporated in an exemplaryportable computing device (PCD) 700. The SoC 322 may include a multicoreCPU 702. The multicore CPU 702 may include a zeroth core 710, a firstcore 712, and an Nth core 714. One of the cores may comprise, forexample, a graphics processing unit (GPU) with one or more of the otherscomprising the CPU.

A display controller 328 and a touch screen controller 330 may becoupled to the CPU 802. In turn, the touch screen display 706 externalto the on-chip system 322 may be coupled to the display controller 328and the touch screen controller 330.

FIG. 7 further shows that a video encoder 334, e.g., a phase alternatingline (PAL) encoder, a sequential color a memoire (SECAM) encoder, or anational television system(s) committee (NTSC) encoder, is coupled tothe multicore CPU 702. Further, a video amplifier 336 is coupled to thevideo encoder 334 and the touch screen display 706. Also, a video port338 is coupled to the video amplifier 336. As shown in FIG. 7, auniversal serial bus (USB) controller 340 is coupled to the multicoreCPU 702. Also, a USB port 342 is coupled to the USB controller 340.Memory 104 and a subscriber identity module (SIM) card 346 may also becoupled to the multicore CPU 702. Memory 104 may reside on the SoC 322or be coupled to the SoC 322.

Further, as shown in FIG. 7, a digital camera 348 may be coupled to themulticore CPU 702. In an exemplary aspect, the digital camera 348 is acharge-coupled device (CCD) camera or a complementary metal-oxidesemiconductor (CMOS) camera.

As further illustrated in FIG. 7, a stereo audio coder-decoder (CODEC)350 may be coupled to the multicore CPU 702. Moreover, an audioamplifier 352 may coupled to the stereo audio CODEC 350. In an exemplaryaspect, a first stereo speaker 354 and a second stereo speaker 356 arecoupled to the audio amplifier 352. FIG. 7 shows that a microphoneamplifier 358 may be also coupled to the stereo audio CODEC 350.Additionally, a microphone 360 may be coupled to the microphoneamplifier 358. In a particular aspect, a frequency modulation (FM) radiotuner 362 may be coupled to the stereo audio CODEC 350. Also, an FMantenna 364 is coupled to the FM radio tuner 362. Further, stereoheadphones 366 may be coupled to the stereo audio CODEC 350.

FIG. 7 further illustrates that a radio frequency (RF) transceiver 368may be coupled to the multicore CPU 702. An RF switch 370 may be coupledto the RF transceiver 368 and an RF antenna 372. A keypad 204 may becoupled to the multicore CPU 702. Also, a mono headset with a microphone376 may be coupled to the multicore CPU 702. Further, a vibrator device378 may be coupled to the multicore CPU 802.

FIG. 7 also shows that a power supply 380 may be coupled to the on-chipsystem 322. In a particular aspect, the power supply 380 is a directcurrent (DC) power supply that provides power to the various componentsof the PCD 700 that require power. Further, in a particular aspect, thepower supply is a rechargeable DC battery or a DC power supply that isderived from an alternating current (AC) to DC transformer that isconnected to an AC power source.

FIG. 7 further indicates that the PCD 700 may also include a networkcard 388 that may be used to access a data network, e.g., a local areanetwork, a personal area network, or any other network. The network card388 may be a Bluetooth network card, a WiFi network card, a personalarea network (PAN) card, a personal area network ultra-low-powertechnology (PeANUT) network card, a television/cable/satellite tuner, orany other network card well known in the art. Further, the network card388 may be incorporated into a chip, i.e., the network card 388 may be afull solution in a chip, and may not be a separate network card 388.

As depicted in FIG. 7, the touch screen display 706, the video port 338,the USB port 342, the camera 348, the first stereo speaker 354, thesecond stereo speaker 356, the microphone 360, the FM antenna 364, thestereo headphones 366, the RF switch 370, the RF antenna 372, the keypad374, the mono headset 376, the vibrator 378, and the power supply 380may be external to the on-chip system 322.

It should be appreciated that one or more of the method steps describedherein may be stored in the memory as computer program instructions,such as the modules described above. These instructions may be executedby any suitable processor in combination or in concert with thecorresponding module to perform the methods described herein.

Certain steps in the processes or process flows described in thisspecification naturally precede others for the invention to function asdescribed. However, the invention is not limited to the order of thesteps described if such order or sequence does not alter thefunctionality of the invention. That is, it is recognized that somesteps may performed before, after, or parallel (substantiallysimultaneously with) other steps without departing from the scope andspirit of the invention. In some instances, certain steps may be omittedor not performed without departing from the invention. Further, wordssuch as “thereafter”, “then”, “next”, etc. are not intended to limit theorder of the steps. These words arc simply used to guide the readerthrough the description of the exemplary method.

Additionally, one of ordinary skill in programming is able to writecomputer code or identify appropriate hardware and/or circuits toimplement the disclosed invention without difficulty based on the flowcharts and associated description in this specification, for example.

Therefore, disclosure of a particular set of program code instructionsor detailed hardware devices is not considered necessary for an adequateunderstanding of how to make and use the invention. The inventivefunctionality of the claimed computer implemented processes is explainedin more detail in the above description and in conjunction with theFigures which may illustrate various process flows.

In one or more exemplary aspects, the functions described may beimplemented in hardware, software, firmware, or any combination thereof.If implemented in software, the functions may be stored on ortransmitted as one or more instructions or code on a computer-readablemedium. Computer-readable media include both computer storage media andcommunication media including any medium that facilitates transfer of acomputer program from one place to another. A storage media may be anyavailable media that may be accessed by a computer. By way of example,and not limitation, such computer-readable media may comprise RAM, ROM,EEPROM, NAND flash, NOR flash, M-RAM, P-RAM, R-RAM, CD-ROM or otheroptical disk storage, magnetic disk storage or other magnetic storagedevices, or any other medium that may be used to carry or store desiredprogram code in the form of instructions or data structures and that maybe accessed by a computer.

Also, any connection is properly termed a computer-readable medium. Forexample, if the software is transmitted from a website, server, or otherremote source using a coaxial cable, fiber optic cable, twisted pair,digital subscriber line (“DSL”), or wireless technologies such asinfrared, radio, and microwave, then the coaxial cable, fiber opticcable, twisted pair, DSL, or wireless technologies such as infrared,radio, and microwave are included in the definition of medium.

Disk and disc, as used herein, includes compact disc (“CD”), laser disc,optical disc, digital versatile disc (“DVD”), floppy disk and blu-raydisc where disks usually reproduce data magnetically, while discsreproduce data optically with lasers. Combinations of the above shouldalso be included within the scope of computer-readable media.

Alternative embodiments will become apparent to one of ordinary skill inthe art to which the invention pertains without departing from itsspirit and scope. Therefore, although selected aspects have beenillustrated and described in detail, it will be understood that varioussubstitutions and alterations may be made therein without departing fromthe spirit and scope of the present invention, as defined by thefollowing claims.

1. A system for managing hardware limits on a system on chip (SoC), thesystem comprising: a plurality of chip components provided on a systemon chip (SoC); a network of local limit manager (LLM) componentsdistributed on the SoC, each LLM component in communication with acorresponding sensor module that monitors one or more of the chipcomponents, each LLM component comprising a generic hardware structurefor enforcing one or more hardware limits associated with thecorresponding sensor module.
 2. The system of claim 1, wherein the chipcomponents comprise one or more of a central processing unit (CPU), agraphics processing unit (GPU), and a digital signal processor (DSP). 3.The system of claim 1, wherein one or more of the sensor modulescomprise a digital power meter (DPM) configured to store estimatedcurrent consumption of the monitored chip component in a sensor dataregister embodied in the corresponding LLM component.
 4. The system ofclaim 3, wherein the LLM component embodying the sensor data register isconfigured to: compare the estimated current consumption stored in thesensor data register against a local hardware limit stored in a limitsthreshold register; and if the local hardware limit is exceeded,initiate one or more throttling actions defined in a throttling actionregister.
 5. The system of claim 1, wherein the one or more hardwarelimits comprise one or more of a power delivery network (PDN) transientlimit, a current limit, a thermal limit, a battery current limit, and avoltage rail current limit associated with power management integratedcircuit (PMIC) or a switched mode power supply (SMPS).
 6. The system ofclaim 1, wherein the generic hardware structure of each LLM comprises: asensor data register for storing the sensor data from the associatedsensor module; a threshold register for storing one or more coefficientsfor determining whether the sensor data exceeds the one or more hardwarelimits; and a throttling actions register for storing one or morepredefined throttling actions to be initiated if the sensor data exceedsthe one or more hardware limits.
 7. The system of claim 1, wherein theLLM components are configured to sample the sensor data at aprogrammable time constant.
 8. The system of claim 1, further comprisingone or more domain limit manager (DLM) components residing on the SoC,each DLM component in communication with a portion of the plurality ofLLM components in a parent/child relationship, wherein the parent DLMcomponent is configured to budget the one or more hardware limits to theplurality of associated child LLM components.
 9. The system of claim 8,wherein each DLM component comprises a separate voltage domainassociated with a corresponding switched mode power supply (SMPS). 10.The system of claim 8, wherein one or more of the DLM components isconfigured to budget a battery current consumption to the associatedchild LLM components.
 11. A method for providing hardware limitmanagement and enforcement, the method comprising: a sensor modulemonitoring a chip component on a system on chip (SoC); storing sensordata from the sensor module in a local limit management (LLM) hardwarecomponent; storing a hardware limit associated with the sensor module inthe LLM hardware component; comparing the sensor data to the hardwarelimit; and if the sensor data exceeds the hardware limit, initiating apredefined throttling action for enforcing the hardware limit, whereinthe hardware limit comprises one or more of a power delivery network(PDN) transient limit, a current limit, a thermal limit, a batterycurrent limit, and a voltage rail current limit associated with powermanagement integrated circuit (PMIC) or a switched mode power supply(SMPS).
 12. The method of claim 11, wherein the chip component comprisesone or more of a central processing unit (CPU), a graphics processingunit (GPU), and a digital signal processor (DSP).
 13. The method ofclaim 11, wherein the sensor module comprises a digital power meter(DPM) and the sensor data comprises estimated current consumption of themonitored chip component.
 14. (canceled)
 15. The method of claim 11,wherein the hardware limit is programmable.
 16. The method of claim 11,wherein the storing the sensor data in the LLM hardware componentfurther comprises sampling the sensor data at a predefined timeconstant.
 17. The method of claim 11, further comprising: associatingthe LLM hardware component with a domain limit manager (DLM) componentin a parent/child relationship, wherein the parent DLM component isconfigured to budget the hardware limit to the child LLM components. 18.The method of claim 17, wherein the sensor data comprises an estimatedcurrent consumption of the monitored chip component, and the parent DLMcomponent budgets a battery current consumption to the child LLMcomponents.
 19. A system for providing hardware limit management andenforcement, the system comprising: means for monitoring a chipcomponent on a system on chip (SoC); means for storing sensor data fromthe sensor module in a local limit management (LLM) hardware component;means for storing a hardware limit associated with the sensor module inthe LLM hardware component; means for comparing the sensor data to thehardware limit; and means for initiating a predefined throttling actionfor enforcing the hardware limit if the sensor data exceeds the hardwarelimit.
 20. The system of claim 19, wherein the chip component comprisesone or more of a central processing unit (CPU), a graphics processingunit (GPU), and a digital signal processor (DSP).
 21. The system ofclaim 19, wherein the means for monitoring the chip component comprisesa digital power meter (DPM) and the sensor data comprises estimatedcurrent consumption of the monitored chip component.
 22. The system ofclaim 19, wherein the hardware limit comprises one or more of a powerdelivery network (PDN) transient limit, a current limit, a thermallimit, a battery current limit, and a voltage rail current limitassociated with power management integrated circuit (PMIC) or a switchedmode power supply (SMPS).
 23. The system of claim 19, wherein thehardware limit is programmable.
 24. The system of claim 19, wherein themeans for storing the sensor data in the LLM hardware component furthercomprises means for sampling the sensor data at a predefined timeconstant.
 25. The system of claim 19, further comprising: means forassociating the LLM hardware component with a domain limit manager (DLM)component in a parent/child relationship, wherein the parent DLMcomponent is configured to budget the hardware limit to the child LLMcomponents.
 26. The system of claim 25, wherein the sensor datacomprises an estimated current consumption of the monitored chipcomponent, and the parent DLM component budgets a battery currentconsumption to the child LLM components.
 27. A system for managing andenforcing hardware limits on a system on chip (SoC), the systemcomprising: a system on chip comprising a plurality of chip components;and an interconnected network of local limit manager (LLM) componentsdispersed over an area of the SoC, each LLM component in communicationwith a corresponding sensor module that monitors one or more of the chipcomponents, each LLM component comprising a generic hardware structurefor enforcing one or more hardware limits associated with thecorresponding sensor module; wherein the generic hardware structure ofeach LLM comprises: a sensor data register for storing the sensor datafrom the associated sensor module; a threshold register for storing oneor more coefficients for determining whether the sensor data exceeds theone or more hardware limits; and a throttling actions register forstoring one or more predefined throttling actions to be initiated if thesensor data exceeds the one or more hardware limits.
 28. The system ofclaim 27, wherein an estimated current consumption of the monitored chipcomponent is stored in the sensor data register, and the LLM componentembodying the sensor data register is configured to: compare theestimated current consumption stored in the sensor data register againsta local hardware limit stored in a limits threshold register; and if thelocal hardware limit is exceeded, initiate one or more throttlingactions defined in the throttling action register.
 29. The system ofclaim 27, wherein the one or more hardware limits comprise one or moreof a power delivery network (PDN) transient limit, a current limit, athermal limit, a battery current limit, and a voltage rail current limitassociated with power management integrated circuit (PMIC) or a switchedmode power supply (SMPS).
 30. The system of claim 27, further comprisingone or more domain limit manager (DLM) components residing on the SoC,each DLM component in communication with a portion of the plurality ofLLM components in a parent/child relationship, wherein the parent DLMcomponent is configured to budget the one or more hardware limits to theplurality of associated child LLM components.